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DETAILED ACTION 
Response to Amendment 

This Office Action is responsive to the amendment filed on 01/06/2010. 
Claims 1 and 13 have been amended. 

Claims 1-8, 10-27, 33-37, 41-43, 45, 48, 51-52, 55-60, 62, 66-73, 79-82 and 88-99 are pending in 

the application. 

1 . Applicant's request for reconsideration of the finality of the rejection of the last Office 
action is persuasive and, therefore, the finality of that action is withdrawn. 

Claim Rejections - 35 USC §103 

2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A palcnl may nol be oblaincd Ihough the invention is not identically disclosed or described as set Ibrth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 
(1966), that are applied for establishing a background for determining obviousness under 35 
U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness 
or nonobviousness. 
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1 . Claims 1-8, 10-27, 33-36, 88-98 rejected under 35 U.S.C. 103(a) as being unpatentable 
over Yaport et al. (US 2002/0178221 Al), hereinafter Yaport in view of Cai et al. (US 
2005/0030966 Al), hereinafter referred to as Cai. 

Regarding claim 1. Yaport discloses a method of multicasting a data file, (see title, abstract and 
fig.2), comprising: 

transmitting a notification on an upcoming multicast transmission to a plurality of 
receivers designated to receive the multicast transmission, (transmission: distribution for 
multicast data: [0033]-[0047], for notification, applicable to users of cellular phones, [0089], 
[0090]), 

transmitting a data file, (data is transmitted to the client 104), from a data server, 
([0033], [0036], [0037]: server 100), on the one or more multicast channels, (multicast data 
transmission means such as a router 102), without the data server receiving acknowledgements 
from the receivers on whether they received the notification, ([0035], [0042], [0081], [0088]: 
data transmission without client-server sessions and acknowledgement) 

determining at least one of the plurality of the receivers that received at least a portion of 
the data file, (the information is transmitted by portions, known as protocol data units: [0042] for 
delivery of small portions). 
Yaport does not explicitly disclose the steps of: 

determining receivers designated to receive the multicast transmission that did not 
receive at least a portion of the data file 

attempting to deliver the data file to the determined receivers 
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Cai teaches Multimedia Broadcast Multicast Service (MBMS) service where one use of MBMS 
services may be to broadcast an event that includes multiple communication sessions, that is to 
transmit portion of the data for providing missing data or replays of data to subscribers. Cai 
teaches, fig. 4A step 424, determining whether a second set of data (or portion of data) is 
received by the subscriber), [0048], [0052], that the MS has not previously received. Cai further 
discloses an attempt to deliver the data to the MS; for, [0054], by providing a Session 
Description in the sets of data packets conveyed to the MSs 102-104 associated with subscribers 
to the MBMS service and in an MBMS notification conveyed to the MSs, communication 
system 100 permits the MSs to determine whether to receive re-data broadcasts by the MBMS 
service 

It would have been obvious to a person of ordinary skill at the time the invention was made to 
implement Yaport with the teaching of Cai so that chents can subscribe to a particular or selected 
multicast group at any time and missing data or replays of data to subscribers is provided. 
Regarding claim 2 . Yaport discloses transmitting the notification comprises transmitting on a 
multicast or broadcast channel, [0031] 

Regarding claim 3. Yaport discloses transmitting the notification comprises transmitting a 
unicast notification to each of the receivers on the designated receivers, ([0020]: fig. 1 is a very 
schematic representation of an existing system for unicast connection) 
Regarding claim 4, Yaport discloses transmitting the notification comprises transmitting 
substantially only to designated receivers, (by sending multicast data to members of the 
multicast group: the users who agree with the service provider or operator on the conditions 
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regarding the provision of the multicast service and who indicate willingness or readiness to 
receive the multicast service are the designated receivers, [0040]). 

Regarding claim 5. Yaport discloses transmitting the notification comprises transmitting a 
message open also to non-designated receivers, (the multicast data source is the server 100 (figs. 
6-9) assuring Multimedia Broadcast Multicast Service (MBMS); thus in the broadcast mode the 
data is transmitted to all users in one or more broadcast areas, (this includes also non-designated 
receivers). 

Regarding claim 6. Yaport discloses the notification indicates the one or more channels on 
which the multicast transmission will be provided, ([0090] the immediate notification indicates 
that one client may have capability of receiving the selected information in parallel mode but via 
several different speed channels simultaneously). 

Regarding claim 7. Yaport discloses tuning to the multicast channel by at least one of the 
receivers comprises determining by each receiver that receives the notification whether to tune 
onto the one or more multicast channels, ([0090]) 

Regarding claim 8. Yaport discloses determining by each receiver that receives the notification 
whether to tune onto the one or more multicast channels comprises determining, from the 
notification, a group to which the upcoming multicast transmission belongs and determining 
whether to tune onto the one or more multicast channels according to the determined group, 
(note group can vary depending on the nature of the service, any client can subscribe to a 
particular multicast group for receiving the data; for example reference numeral 44 is the 
Intemet, and 42-1, 42-2, 42-3 are clients of group 42; 40-1, 40-2 are chents of group 40, etc.). 
Regarding claim 10. Yaport discloses determining by each receiver that receives the notification 
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whether to tune onto the one or more multicast channels comprises determining based on input 
received from a user responsive to the notification, ([0063]: the client 104-1 receives the 
randomly selected initial PDU in response to the request Rl, as "On Demand" attempt to 
transport the program or show from a central repository (server) to the user (client) in response to 
his/her request. To initiate the request, the user selects from a list of candidate programs and 
requests that the system deliver the selected program.). 

Regarding claim 11. the receivers do not transmit acknowledgements of reception of the 
notification, at all, (Yaport discloses, [0017], [0081], [0088]: connection is confirmed by 
acknowledgement, and the data is transmitted to the client 26-1 via the established connection; 
Regarding claim 12. Yaport does not explicitly disclose that the receivers cannot transmit uplink 
messages to the data server, without stopping to listen to the one or more multicast channels. 
Cai discloses [0028] uplink 135 that includes multiple communication channels, comprising 
[0031], one or more of muUiple time slots in a same frequency bandwidth. 
Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so that receivers can particularly select one 
or more multicast group. 

Regarding claim 13. attempting to deliver the data file comprises delivering the data file in a 

unicast transmission to each of the determined receivers. 

Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to fransfer to clients of a particular group of multicast groups, [0031] for, a plurality of individual 
sessions occurs between individual clients and the server(s) consisting of unicast fransmission: 
[0014], [0016], [0020]. 
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Regarding claim 14. attempting to deliver the data file comprises delivering the data file in a 
multicast transmission to a plurality of the determined receivers, (by sending multicast data to 
members of the multicast group: the users who agree with the service provider or operator on the 
conditions regarding the provision of the multicast service and who indicate willingness or 
readiness to receive the multicast service are the designated receivers). 
Regarding claim 15. attempting to deliver the data file comprises providing a notification 
message inviting the receivers to download the transmission on a unicast connection, to the 
determined receivers. 

Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to transfer to clients of a particular group of multicast groups, [003 1] for, a plurality of individual 
sessions occurs between individual clients and the server(s) consisting of unicast transmission: 
[0014], [0016], and [0020]. 

Regarding claim 16 , at least 80% of the designated receivers establish only a single unicast 
connection related to receiving the data file. 

Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to transfer to clients of a particular group of multicast groups, [0031] for, a plurality of individual 
sessions occurs between individual clients and the server(s) consisting of unicast transmission: 
[0014], [0016], [0020]. 

Regarding claim 17, substantially all of the designated receivers establish only a single unicast 
connection related to receiving the data file. 

Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to transfer to clients of a particular group of multicast groups, [0031] for, a plurality of individual 
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sessions occurs between individual clients and the server(s) consisting of unicast transmission: 
[0014], [0016], [0020]. 

Regarding claim 18. all of the designated receivers establish up to two single unicast 
connections related to receiving the data file. 

Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to transfer to clients of a particular group of multicast groups, [003 1] for, a plurality of individual 
sessions occurs between individual clients and the server(s) consisting of unicast transmission: 
[0014], [0016], [0020]. 

Regarding claim 1 9 , Yaport does not explicitly disclose at least a portion of the data file is 
encrypted, requiring one or more decryption keys identified in the transmitted data file. 
Cai discloses [0020], [0030], [0036], [0050] a keypad that includes multiple keys via which a 
user of the MS may input an instruction to the MS. Therefore, it would have been obvious to a 
person of ordinary skill at the time the invention was made to implement Yaport with the 
teaching of Cai so as to conveys a response to server 118 indicating a desire of a user of the MS 
to subscribe to the event. 

Regarding claim 20. Yaport does not explicitly disclose the receivers request the one or more 
keys after receiving the data file. 

Cai discloses [0020], [0030], [0036], [0050] a keypad that includes multiple keys via which a 
user of the MS may input an instruction to the MS. Therefore, it would have been obvious to a 
person of ordinary skill at the time the invention was made to implement Yaport with the 
teaching of Cai so as to conveys a response to server 118 indicating a desire of a user of the MS 
to subscribe to the event. 
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Regarding claim 21 , Yaport does not explicitly disclose at least one of the receivers requests the 
one or more keys, 

Cai discloses a keypad that includes multiple keys [0020], [0030], [0036], [0050], that the user 
may select or a key of a keypad that a user may depress to generate a response. 

Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so as to conveys a response to server 118 
indicating a desire of a user of the MS to subscribe to the event. 

Regarding claim 22. Yaport does not explicitly disclose the receivers request the one or more 
keys after determining that they received sufficient data to allow reconstruction of the data file, 
Cai, [0050], discloses that the retrieved message may instruct the user to select one key of a 
keypad if the user's response is affirmative and to select another key of the keypad if the user's 
response is negative; therefore, the retrieved message is thus displayed by processor 206 and the 
message is retrieved (reconstructed) on the display screen of user interface 210. 
Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so as to conveys a response to server 118 
indicating a desire of a user of the MS to subscribe to the event. 

Regarding claim 23. Yaport discloses the claimed invention except that the keys are received on 
a single unicast connection along with any supplementary data required, not received during the 

multicast transmission. 

Yaport discloses the supplementary data reception, (PDUCl, PDUC2: they are intended for 
improving rehability of data transmission, [0045]-[0046]; data distribution over the channels of 
one of the channel groups, e.g., 130, so as to transfer to clients of a particular group of multicast 
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groups, [003 1] for, a plurality of individual sessions occurs between individual clients and the 
server(s) consisting of unicast transmission: [0014], [0016], [0020]. 

Regarding claim 24. Yaport does not explicitly disclose the steps of receiving acknowledgements 
from receivers that received the notification or at least a portion of the data file, after 

transmitting the data file, wherein determining receivers designated that did not receive at least 
a portion of the data file is performed by determining receivers from which acknowledgments 
were not received. 

Cai teaches Multimedia Broadcast Multicast Service (MBMS) service where one use of MBMS 
services may be to broadcast an event that includes multiple communication sessions, that is to 
transmit portion of the data for providing missing data or replays of data to subscribers. Cai 
teaches, fig. 4A step 424, determining whether a second set of data (or portion of data) is 
received by the subscriber), [0048], [0052], that the MS has not previously received. Cai further 
discloses an attempt to deliver the data to the MS; for, [0054], by providing a Session 
Description in the sets of data packets conveyed to the MSs 102-104 associated with subscribers 
to the MBMS service and in an MBMS notification conveyed to the MSs, communication 
system 100 permits the MSs to determine whether to receive re-data broadcasts by the MBMS 
service 

It would have been obvious to a person of ordinary skill at the time the invention was made to 
implement Yaport with the teaching of Cai so that clients can subscribe to a particular or selected 
multicast group at any time and missing data or replays of data to subscribers is provided. 
Regarding claim 25. Yaport does not explicitly disclose receiving the acknowledgements 
comprises receiving a request for decryption keys. 
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Cai discloses, [0030], [0036], [0050], The retrieved message may further include a "Yes" 
response and a "No" response when the display screen of user interface 210 is a touch screen, or 
may instruct the user to select one key of a keypad if the user's response is aflfirmative and to 
select another key of the keypad if the user's response is negative. Therefore, it would have been 

obvious to a person of ordinary skill at the time the invention was made to implement Yaport 
with the teaching of Cai so as to conveys a response to server 118 indicating a desire of a user of 
the MS to subscribe to the event. 

Regarding claim 26. receiving the acknowledgements comprises receiving a request for 

supplementary data not received during the multicast transmission. 

Yaport discloses receiving multicast data in the form of protocol data units PDUl, PDU2, PDU3, 
PDU4 , so that if any informational PDU such as PDUCl, PDUC2 ... is lost during the 
transmission, the control protocol data units of all data segments will allow to restore the missing 
data , [0046]. 

Regarding claims 27 . receiving the acknowledgements comprises receiving over a different 
network than the network on which the data file was multicast. 

Yaport discloses, [0017], if for some reason the acknowledgement is not received, the server will 
retransmit the data within two minutes. 

Regarding claim 33 , attempting to deliver the data file to the determined receivers comprises 
delivering on a different network than the network on which the data file was multicast. 
Cai teaches, fig. 4A step 424, determining whether a second set of data (or portion of data) is 
received by the subscriber), [0048], [0052], that the MS has not previously received. Cai further 
discloses an attempt to deliver the data to the MS; for, [0054], by providing a Session 
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Description in the sets of data packets conveyed to the MSs 102-104 associated with subscribers 
to the MBMS service and in an MBMS notification conveyed to the MSs, communication 
system 100 permits the MSs to determine whether to receive re-data broadcasts by the MBMS 
service 

It would have been obvious to a person of ordinary skill at the time the invention was made to 
implement Yaport with the teaching of Cai so that chents can subscribe to a particular or selected 
multicast group at any time and missing data or replays of data to subscribers is provided. 
Regarding claim 34 . the notification indicates a plurality of categories to which the data file 
relates and the plurality^ of receivers comprises receivers designated to receive data belonging to 
different ones of the plurality of categories, (Yaport discloses capability of receiving the selected 
information or notification in parallel mode but via several different speed channels 
simultaneously, [0090]: this indicates the plurality of categories relates such as text, audio, video, 
and interlaced computer programs; [0005]) 

Regarding claim 35. transmitting the data file comprises transmitting a plurality of subfiles in a 
plurality of separate transmission sessions, ([0035]: file is divided into data segments, the data 
segments are distributed between data transmission units 114 and 116: [0037]) 

Regarding claim 36 , transmitting the data file comprises transmitting a plurality subfiles on a 

plurality of different channels. 

Yaport discloses the data segments are distributed between data transmission units 114 and 116: 
[0037]) 
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2. Claims 37, 41-43, 45, 48, 51, 52, and 55 rejected under 35 U.S.C. 103(a) as being 
unpatentable over Xu et al. (US 2006/0166653 Al), in view of Dillon (US 6728878). 
Regarding claim 37. Xu discloses a method of receiving a data file provided in a multicast 
transmission, (fig. 2 multicast data reception step 218), comprising: 

tuning, by a mobile station, onto a multicast channel, (fig. 1 and [0038] the message to 
inform the MS of upcoming multicast session: note fig. 3 step 308. When this notification 
arrives, the mobile station changes to the multicast reception mode, (tune) where it listens to the 
MBMS data channel in order to receive the service data (step 308) transmitted on that channel, 
[0060], [0061]); 

receiving at least one encrypted packet which can be used in reconstructing the data file, 
(note MS receiving the service notification [0068], also receives a Message Authentication Code 
(MAC) included in a message to provide authenticity; this indicates encrypted packet. Thus, the 
MAC is a value derived from the message by a key-dependent one-way function (such as the 
widely used HMAC). Only the party possessing the key can create or verify the MAC), on the 
multicast channel; and 

receiving at least one key required for decrypting the at least one packet after receiving a 
sufficient number of packets for reconstructing the data file, ( [0069], [0070], [0071], [0072]: a 
mobile station needs a key to unlock an encrypted packet. 

Although Xu discloses receiving a key for decrypting multicast data, Xu does not expUcitly 
disclose receiving the key as required in the claim. 
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Dillon, in a document delivery system, discloses each document sent from broadcast center 150 
is decrypted with a different key (to decrypt the received packets), packetized, encrypted 
documents, col. 6 lines 61-67. With reference to the timing chart of figs. Sand 6, and the Table of 
cols. 7 and 8, Dillon further discloses that each document sent fi-om broadcast center 150 is 
decrypted with a key received in the announcement message: see F5 and F6 for receiving the key 
and receiving and decrypting packet with the key). It would have been obvious to a person of 
ordinary skill at the time the invention was made to implement Xu with the teaching of Dillon so 
that a client (a user) determines which document to receive and for which only he or she is 
charged for. 

Regarding claim 41. requesting the at least one key after receiving a sufficient number of packets 
for reconstructing the data file and wherein receiving the at least one key is performed 
responsive to the requesting, pCu discloses the data is transmitted to all users in one or more 
broadcast areas, whereas in the multicast mode the data is transmitted to a multicast group in a 
multicast area, [0069]). 

Dillon discloses that each document sent from broadcast center 150 is decrypted with a key 
received in the announcement message: therefore see F5 and F6 for receiving the key and 
receiving and decrypting packet with the key). It would have been obvious to a person of 
ordinary skill at the time the invention was made to implement Xu with the teaching of Dillon so 
that a client (a user) determines which document to receive and for which only he or she is 
charged for. 

Regarding claim 42. Xu discloses the requesting of the at least one key is performed responsive 
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to a user instruction, (following the user's authorization, [0066], the MAC is a value derived 
from the message by a key-dependent one-way function, [0068]). 

Regarding claim 43. Xu discloses at least a portion of the data file is not encrypted and the user 
instruction is received after displaying the non-encrypted portion of the file to the user ([0068]: a 
Message Authentication Code (MAC) can be included in a message to provide authenticity 
without secrecy (that is non encrypted); this forms the user instruction received by the user). 
Dillon discloses, see table of col. 8, the fimction of displaying a catalog and processing 
document requests. It would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Xu with the teaching of Dillon so that a cHent (a user) 
determines which document to receive and for which only he or she is charged for. 
Regarding claim 45. the non-encrypted portion of the file is received before any encrypted 
portion of the data file, (Xu disclose receiving the key, corresponding to a non-encrypted 
portion, before the encrypted portion is received because, [0068], a Message Authentication 
Code (MAC) can be included in a message to provide authenticity without secrecy. The MAC is 
a value derived from the message by a key-dependent one-way function (such as the widely used 
HMAC). Only the party possessing the key can create or verify the MAC). 
Regarding claim 48. Xu discloses the file includes a plurality of different portions requiring 
different keys for decryption and wherein the keys required for at least one portion are received 
after displaying at least one other portion, ([0070] However, a different key is used for signing 
the messages and verifying the signatures. A digital signature mechanism is typically 
implemented using public-key cryptography, utilizing the widely used RSA algorithm, for 
example. [0075]: In order to be able to verify the signatures of the mobile stations, the RNC has 
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to be provided with a signature verification key of one or more trusted CAs. In case more than 
one CA is used, their signature keys can either be configured separately to the RNC or certificate 
hierarchy can be utilized. For certificate hierarchy, just a single signature verification key of a 
top-level CA needs to be configured to the RNC: This key is then used to authenticate the 
certificates of lower-level CAs, each containing the signature verification key of that CA. With 
the hierarchical certificates, a mobile station has to include the certificate of a lower-level CA 
with each membership report) 

Regarding claim 51. Xu discloses tuning onto the multicast channel is performed responsive to 
receiving a notification on an upcoming multicast transmission and responsive to a 
determination that the upcoming multicast transmission matches a subscription profile of the 
receiver, (the notification to inform the MS of upcoming multicast session: note fig. 3 step 308: 
{responsive to the notification), when this notification arrives, the mobile station changes to the 
multicast reception mode, where it listens to the MBMS data channel in order to receive the 
service data (step 308) transmitted on that channel, [0060]) 

Regarding claim 52. Xu discloses the determination that the upcoming multicast transmission 
matches a subscription profile of the receiver comprises consulting a multicast subscription 
profile stored on the receiver, (fig. 2 is illustrates the determination (procedure) that the 
upcoming multicast transmission matches a subscription profile of the receiver for the 
establishment for the multicast service. Thus, when a mobile station receives this notification, it 
initiates a response process if it is a member of the group by checking its multicast subscription 
profile, [0045], [0046]) 

Regarding claim 55. Xu discloses acknowledging receipt of the at least one key, in a manner 
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which allows charging for the data file, ([0057]): all the mobile stations will automatically send a 
reply. The operator may wish to do this for charging purposes, for example, [0068]: a Message 
Authentication Code (MAC) can be included in a message to provide authenticity The MAC is a 
value derived from the message by a key-dependent one-way function (such as the widely used 
HMAC). Only the party possessing the key can create or verify the MAC, therefore the mobile 
station acknowledges the possessing the key for charging purposes. 

3. Claims 56-60 and 62 rejected under 35 U.S. C. 103(a) as being unpatentable over Xu, in 
view of Yaport. 

Regarding claim 56. Xu discloses a method of multicasting a file, comprising: 

encrypting the file using one or more keys, ([0071]: a different signing key can be 
provided for each authorized mobile station (source authentication) or the same signing key can 
be shared by all authorized mobile stations (group authentication)); 

transmitting the encrypted file to a plurality of receivers in a multicast transmission, 
(note a message authentication code (MAC) is included in the fransmitted message, therefore the 
need for a key distribution center (KDC) ensures that different signing key can be provided for 
each authorized mobile station to decrypt the encrypted file, [0069]-[0072])); 
and providing at least one of the plurality of receivers with one or more decryption keys required 
for decrypting the transmitted encrypted file, after the file was transmitted, (the mobile station 
obtains a signing key (signing keys provided to the mobiles, from the KDC, for the purpose of 
decrypting the file, [0071]-[0074]). Note fiirther that [0068], a Message Authentication Code 
(MAC) can be included in a message to provide authenticity without secrecy. The MAC is a 
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value derived from the message by a key-dependent one-way function (such as the widely used 
HMAC). Only the party possessing the key can create or verify the MAC, thus showing that the 
key is provided after the message is received. 

Although Xu disclose the message, Xu does not explicitly disclose it as a data file. Yaport 
discloses data files for, [0037], the entire information available to the clients consists of 
individual data items known as files corresponding the message. Therefore, it would have been 
obvious to a person of ordinary skill at the time the invention was made to implement Xu with 
the teaching of Yaport so that the key is provided after the message is received. 
Regarding claim 57 Xu discloses providing at least one of the receivers with at least one 
decryption key for the encrypted file, before transmitting the encrypted file, (the mobile station 
obtains a signing key; signing keys provided to the mobiles, particularly a different key can be 
assigned to each authorized mobile station, [0069], before the transmission of the encrypted file 
because, [0068], a Message Authentication Code (MAC) can be included in a message to provide 
authenticity without secrecy.). 

Regarding claim 58. Xu discloses receiving from the at least one receivers provided with the 
decryption keys before transmitting the encrypted file, acknowledgement messages, 
[0072]: a mobile station needs a key to unlock an encrypted packet. 

Regarding claim 59. Xu discloses the acknowledgement messages are received at least 10 
minutes after the transmission of the encrypted file is completed, (note, [0051] discloses the 
moment for the response to the membership query is determined by setting a timer to a random 
value between zero and the maximum delay value. The idea here is to determine a member- 
specific response moment for each group member present in the cell. The response moment can 
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be determined in many different ways. Instead of setting a timer to a random value, each mobile 
station can, for example, calculate its response moment by means of an algorithm having at least 
one input specific to each mobile station) 

Regarding claim 60. Xu discloses the at least one of the receivers provided with the decryption 
keys before transmitting the encrypted file are selected at least partially responsive to previous 
behavior of the receivers, (note fig. 3 step 308: {responsive to the notification), when this 
notification arrives, the mobile station changes to the multicast reception mode, where it listens 
to the MBMS data channel in order to receive the service data (step 308) transmitted on that 
channel, [0060]; in addition, [0061], [0071], a different signing key, (decryption keys), can be 
provided for each authorized mobile station before the transmission of the encrypted file). 
Regarding claim 62. the at least one of the receivers provided with the decryption, ([0070], 
[0071], [0072] and [0073]: note, by first obtaining a signing key and a certificate containing the 
corresponding signature verification key from a Key Distribution Center (KDC) which creates 
the MAC keys and delivers them seciirely (with authentication and secrecy) to the authorized 
mobile stations, at least a portion of the data file is thus encrypted), keys before transmitting the 
encrypted file are selected at least partially responsive to the number or percentage of 
acknowledgements provided by the receivers in a given period, 

Xu teaches the claimed invention, (transmitting the encrypted file responsive to the notification, 
fig. 3 step 308) but does not explicitly disclose the transmission responsive to the number or 
percentage of acknowledgements provided by the receivers in a given period. Xu teaches further, 
a response time period for the receivers for, [0057]: the maximum value of the response time 
may also be known to the mobile station in advance. 



Application/Control Number: 10/574,240 Page 20 

Art Unit: 2472 

Yaport teaches, [0017] and fig. 1, that for the data to be transmitted to the clients, the protocol 
the connection is confirmed by acknowledgement so that reception of the information by the 
client must be confirmed by a separate acknowledgment for each separate protocol data unit. 
Therefore it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Xu with Yaport, to differentiate receivers, or to assure QoS based on 
percentage of acknowledgements provided. 

4. Claims 79, 82 rejected under 35 U.S.C. 103(a) as being unpatentable over Siren 
(2002/0006801 Al) in view Sasvari et al. (US 2004/0057376 Al), 

Regarding claim 79 , Siren discloses a method of transmitting multicast data in a cellular 

network, comprising: 

providing data for multicast transmission, ([0046], [0047], [0049], [0050]), to a plurality 
of base stations, having different bandwidth amounts for multicast transmission, at a same rate 
([0035]: different bandwidth allocation to a plurality of base stations in a wireless network to 
assure group or multicast transmission over the wireless network). 
Siren teaches the claimed invention except explicitly 

dropping data by one or more of the base stations, as required, so that the data can be 
transmitted by each of the base stations on its respective allocated bandwidth for multicast 
transmission; and 

transmitting the non-dropped data such that the data is transmitted by all the base stations 
substantially synchronously. 
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Sasvari discloses, [001 1], [0023], in a communications system a finite bandwidth for the 
communication of traffic of a plurality of users; the communications system further comprises 
packet discard means for discarding (or dropping) packets, on an individual basis, in a pseudo- 
random fashion so that data transmitted to the system has a finite bandwidth for carrying the 

traffic; 

Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to modify Siren with the teaching of Sasvari, to maintain the communication of traffic of a 
plurality of users in which the system has a finite bandwidth for carrying the traffic. 

5. Claim 80 rejected under 35 U.S.C. 103(a) as being unpatentable over Siren in view 
Sasvari and further in view of Okada (US 2002/0012327 Al). 
Regarding claim 80 , Siren discloses the base stations except explicitly: 

the base stations use a small buffer, having room for at most five packets, for the 
provided multicast data, 

Okada discloses, fig. 25, a base station 2501, as a general base station that includes a 
forwarding unit 2505 which has a buffer 2504 for forwarding to a multicast address. [0223]- 
[0225]: the buffer stores packets which is transmitted or forwarded to other locations. Therefore, 
it would have been obvious to a person of ordinary skill at the time the invention was made to 
modify Siren in view of Sasvari with the teaching of Okada to maintain flow performance based 
on the buffer state of the base station. 
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6. Claims 81 and 99 rejected under 35 U.S.C. 103(a) as being unpatentable over Siren in 
view of Tasman et al (2002/0080755 Al). 

Regarding claims 81 and 99 . providing the data, comprises providing data protected with a 
forward error correction code, 

Siren teaches the claimed invention except explicitly the data provided does not comprise 
providing data protected with a forward error correction code. 

Tasman, by disclosing that communication occurs from the server to the client without 
acknowledgement or confirmation, many telephone and computer communication channels 
presume that data is lost if no acknowledgement is received and retransmit the lost data, resulting 
in forward error correction. It would have been obvious to a person of ordinary skill at the time 
the invention was made to modify Siren with Tasman to incorporate forward error correction 
(FEC), for (FEC) software may reduce the number of retransmissions by alleviating some 
portion of the data packet loss. 

Regarding claim 82. Siren discloses transmitting supplementary data to receivers that request 
data they did not receive in the multicast transmission over point-to-point connections, ([0035] 
channels allocated to individual point-to-point user channels having a single recipient). 

Regarding claim 88. Yaport discloses a data server, (figs. 6-9 server 100), comprising: 

an input interface for receiving files to be multicast, ([0033]: as shown in this drawing, the 
system of the invention, as an existing system of FIG. 2, consists of a server 100, a multicast data 
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transmission means such as a router 102, groups of clients 104-1,104-2,104-3 . . . 104-n with 
respective routers 106-1,106-2,106-3, . . . 106-n and the Internet 107 located between the routers 
ofthe groups of clients 104-1,104-1,104-3 . . . 104-n and the router 102); 

an output interface for providing signals for transmission to receivers, ([0033]), 
Yaport discloses a data transmission server 100 for multicast data transmission, (fig. 2), [0031], 
[0032], [0035], to recipients without acknowledgment, thus [0035], [0047]: the muWcast 
distribution does not need confirmation: the server 100 and the method of muhicast data 
transmission without cUent-server sessions and acknowledgement). In addition Yaport teaches 
that information is transmitted by portions, known as protocol data units, [0044]. In addition, 
[0046], the control protocol data units of all data segments will allow to restore the missing data 
(portion of the data or PDU such as PDUCl, PDUC2) lost during the transmission. 

Yaport does not disclose an input interface, an output interface, and a controller as required by 
the claim. 

Cai discloses a server 118 coupled to a RAN controller 1 14 via a support node receives a first set 
of MBMS data from an MBMS content provider, [0020], 

a controller ([0040]: fig. 1, the Radio Access Network further comprises Radio Network 
Controllers (RNC) 1 14), adapted to generate a notification on an upcoming multicast 
transmission, (a multicast service notification is transmitted to mobile stations, thereby 
informing members ofthe multicast group of an upcoming multicast sessions), responsive to a 
received file, to provide the notification through the output interface for transmission and to 
provide the received file for transmission, (notifying the mobile stations of incoming multicast 
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data), without receiving acknowledgements from the receivers on whether they received the 
notification, to determine receivers designated to receive the multicast transmission that did not 
receive at least a portion of the data file and to attempt to deliver the data file to the determined 
receivers. 

Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so that clients can subscribe to a particular or 
selected multicast group at any time. 

Regarding claim 89. Yaport describes a mobile station, ([0089]: users of cellular phones: not 
shown) comprising: 

a receiver, and 

a processor adapted to tune the receiver to receive data on a plurality of multicast 
channels and to combine the data received on the plurality of channels into a single multimedia 
file, 

Yaport however does not disclose a receiver and a processor as required by the claim. 

Cai discloses a mobile station shown in fig. 1 and further in a block diagram of fig. 2, 
comprising a receiver 202, and a processor 206. Furthermore, Cai teaches that the processor 
receives a plural sets of MBMS data, [0023]. The system assures a transmission (or rebroadcast 
of a Multimedia Broadcast Multicast Service (MBMS) service to the subscribers). 

Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with Cai, to allow data to be transmitted from a single source point to 
multiple endpoints. 
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Regarding claim 90 , Yaport discloses the data received on the plurality of channels, ([0043], and 
fig. 4), comprises different multimedia types on different channels. 

Regarding claim 9 1. determining the receivers that did not receive at least a portion of the data 
file comprises determining receivers that did not receive the data file at all. 
Yaport teaches the claimed invention except explicitly determining the receivers that did not 
receive at least a portion of the data file comprises determining receivers that did not receive the 
data file at all. 

Cai teaches Multimedia Broadcast Multicast Service (MBMS) service where one use of MBMS 
services may be to broadcast an event that includes multiple communication sessions, that is to 
transmit portion of the data for providing missing data or replays of data to subscribers. Cai 
teaches, fig. 4A step 424, determining whether a second set of data (or portion of data) is 
received by the subscriber), [0048], [0052], that the MS has not previously received. Cai further 
discloses an attempt to deliver the data to the MS; for, [0054], by providing a Session 
Description in the sets of data packets conveyed to the MSs 102-104 associated with subscribers 
to the MBMS service and in an MBMS notification conveyed to the MSs, conmiunication 
system 100 permits the MSs to determine whether to receive re-data broadcasts by the MBMS 
service 

It would have been obvious to a person of ordinary skill at the time the invention was made to 
implement Yaport with the teaching of Cai so that clients can subscribe to a particular or selected 
multicast group at any time and missing data or replays of data to subscribers is provided. 

Regarding claim 92. transmitting a data file on the one or more multicast channels comprises 
transmitting the file data a plurality of times, (Y aport teaches [0037]: data or information is 
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divided into a plurality of data segments allowing for a plurality of individual sessions occurring 
between individual clients and the server(s)). 

Regarding claim 94. Yaport teaches providing the notification message comprises sending a 
message to a mail-box of the mobile station, (two-way data commiinication between the 
browsing user, who has a specific electronic address or destination, and the web page, which also 
has a specific electronic destination: [006]) 

Regarding claim 95. Yaport teaches the claimed invention except explicitly the notification 
message comprises providing in an SMS message. 

Cai discloses, [0037], [0037] that the service announcement may be sent in any over-the-air 
format, such as via a broadcast over paging channel 1 3 1 , via a short message service (SMS), or 
via a multicast. It would have been obvious to a person of ordinary skill at the time the invention 
was made to modify Yaport with the teaching of Cai for integration of SMS message allowing 
the interchange of short text messages. 

Regarding claim 96 , at least 80% of the designated receivers establish only a single unicast 
connection related to receiving the data file and transmit only a single request for data. 
Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to transfer to clients of a particular group of multicast groups, [0031] for, a plurality of individual 
sessions occurs between individual clients and the server(s) consisting of unicast transmission: 
[0014], [0016], [0020]. 

Regarding claim 97. the receivers transmit uplink transmissions regarding the multicast 
transmission only after they collected from the multicast channel all the data from the multicast 
channel used in reconstruction the multicast transmission. Cai discloses [0028] uplink 135 that 
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includes multiple communication channels, comprising [0031], one or more of multiple time 
slots in a same frequency bandwidth. 

Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so that receivers can particularly select one 
or more multicast group 

Regarding claim 98. Yaport does not explicitly discloses that at least one of the receivers 
requests the one or more keys from an entity belonging to a different mobile network, 

Cai discloses (multiple softkeys such softkeys corresponding to keys on a conventional telephone 
keypad: [0030], [0036]). Therefore, it would have been obvious to a person of ordinary skill at 
the time the invention was made to implement Yaport with the teaching of Cai so that receivers 
can particularly select one or more multicast group so as to provide a response to server 
indicating a desire of a user of the MS to subscribe to the event) 

7. Claim 93 rejected under 35 U.S.C. 103(a) as being unpatentable over Yaport in view of 
Cai and further in view of Tasman et al. (US 2002/0080755 Al). 

Regarding claim 93. transmitting the data file comprises transmitting the file protected with a 

forward error correction code. 

Yaport teaches the claimed invention except explicitly transmitting the file protected with a 
forward error correction code. 

Tasman, [0048], in disclosing a mechanism for forwarding layer interfacing for networks, 
teaches encoding resulting in forward error correction (FEC). It would have been obvious to a 
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person of ordinary skill at the time the invention was made to modify Yaport with Tasman to 
incorporate forward error correction (FEC), for (FEC) software may reduce the number of 
retransmissions by alleviating some portion of the data packet loss. 



Allowable Subject Matter 

8. Claims 66-73 are allowed. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to EMMANUEL MAGLO whose telephone number is (571)270- 
1854. The examiner can normally be reached on Monday - Thursday 7:00 - 4:30 and every other 
Friday 7:00 -3:30. 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, William Trost can be reached on (571)272-7872. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Elecfronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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